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Enabling  Software  Acquisition  Improvement: 
Government  and  Industry  Software  Development 
Team  Acquisition  Model 


Joe  Heil — Joe  W.  Heil  has  worked  as  a  Software  Engineer  for  the  Naval  Surface  Warfare  Center 
Dahlgren  Division  (NSWCDD)  for  over  23  years.  The  majority  of  Mr.  Heil's  career  was  spent  as  the 
Software  Integrated  Product  Team  Lead  for  the  Tomahawk  Weapon  Control  System  (TTWCS).  As  the 
TTWCS  SW  IPT  lead,  he  was  responsible  for  defining  the  software  development  processes  and 
coordinating  the  software  development  efforts  for  the  TTWCS  integrated  Industry  and  Government 
software  development  team.  Mr.  Heil  is  currently  the  Senior  Software  Engineer  for  the  NSWCDD 
Strategic  and  Weapons  Control  Systems  Department  (K)  and  is  focused  on  improving  software 
engineering,  development,  and  acquisition. 


Abstract 

The  growth,  complexity,  and  reliance  on  software  (SW)  as  part  of  the  Department  of 
Defense  and  Navy  (DoD/Navy)  warfare  systems  is  continuing  to  increase.  This  increase  in 
SW  complexity  and  reliance  has  been  accompanied  by  an  increase  in  well  documented  SW 
intensive  system  acquisition  cost,  schedule  and  technical  performance  failures.  The 
DoD/Navy  is  not  consistently  performing  as  a  smart  buyer  of  software  intensive  systems. 
The  government  and  private  industry  have  not  been  successful  in  applying  the  latest 
software  methodologies  and  technologies  nor  consistently  providing  high  quality  and  reliable 
systems  that  are  delivered  on  schedule  and  within  budget.  The  typical  acquisition  approach 
utilized  over  the  past  several  decades  of  relying  primarily  on  private  industry  for 
architecting,  designing  and  implementing  SW  intensive  systems  has  resulted  in  the  loss  of 
government  in-house  applied  SW  expertise  necessary  to  achieve  truly  open  architected 
systems  and  systems-of-systems. 

The  key  enablers  for  improving  SW  intensive  system  acquisition  are  the 
reconstitution  and  utilization  of  government  in-house  software  subject  matter  experts 
(SMES)  that  can  lead  and  work  with  industry  SW  engineers  as  part  of  an  integrated  SW 
Development  Team.  Figure  1  summarizes  the  current  state  and  desired  future  state  trends. 


Figure  1.  SW  Acquisition  Trends 
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Current  State:  SW  Technical  Challenges 

There  are  numerous  technical  challenges  associated  with  the  growth  and  reliance  on 
software  within  the  DoD/Navy’s  mission  critical  warfare  systems  such  as: 

■  Designing  and  implementing  truly  Open  Architected  systems  that  fully  meet  the 
goals  of  standardized  interfaces,  scalability,  reliability,  portability,  modularity  and 
reusability;  and  thereby  lead  to  higher  system  quality  while  also  reducing  cost 
and  schedule. 

■  Assessing,  successfully  utilizing,  and  rapidly  integrating  the  most  advanced 
software  technologies  and  methodologies  such  as  Model  Driven  Architectures, 
Service  Oriented  Architectures  (SOA),  multi-core  parallel  processing,  automated 
code  generation,  cloud  computing,  next  generation  programming  languages,  and 
agile  development  processes. 

■  Integrating  the  mix  of  legacy  SW  components,  new  Commercial-Off-The-Shelf 
(COTS)  SW  components  and  DoD/Navy  developed  highly  specialized  and 
unique  SW  components  to  provide  integrated  net-centric  systems  composed  of 
hundreds-of-millions  (possibly  billions)  of  lines  of  code  that  can  execute  as 
systems-of-systems  and  fully  meet  mission  level  objectives  and  Key 
Performance  Parameters  (KPPS). 

■  Achieving  Information  Assurance  (IA)  and  protection  against  SW-based  Cyber- 
Attacks  while  trying  to  maximize  COTS  utilization  and  Net-Centric 
communications. 

■  Maintaining  government  corporate  knowledge  of  the  system  architecture,  design 
and  technology  utilization  as  the  responsibility  for  system  and  software 
development  transitions  among  different  private  industry  organizations  during  the 
program  lifecycle. 

In  order  to  address  the  SW  engineering  and  development  technical  challenges  listed 
above,  as  well  as  many  not  listed  here,  it  is  imperative  that  the  government  maintain  the 
applied  software  technical  experts  that  can  serve  as  both  leaders  and  team-mates  with  peer 
industry  software  engineers. 

Current  State:  Acquisition  Approach 

Figures  2  and  3  provide  high  level  models  with  a  rough  indication  of  the  relative 
involvement  of  government  versus  industry  technical  experts  and  the  typical  acquisition 
approach  utilized  for  SW  Intensive  system  acquisition  and  development.  Government 
engineers  are  primarily  used  during  the  initial  system  concept,  system  level  requirement 
phase,  and  system  validation  phase  of  the  acquisition  process.  In  the  initial  stage  of  system 
acquisition,  the  government  system  engineers  define  the  capability  need  and  the  associated 
highest  level  system  requirements  and  key  performance  parameters  (KPPs).  During  the 
initial  phase,  government  system  engineers  may  work  with  multiple  Industry  organizations  to 
perform  Technical  Assessment  of  Alternatives  (AoA)  where  industry  provide  prototypes  or 
advanced  technology  demonstrations  (often  proprietary)  advertised  to  fully  meet  the  system 
capability  needs  and  can  be  developed  in  a  timely  and  cost  effective  manner. 

The  government  then  relies  almost  entirely  on  Industry  technical  experts  for  the 
detailed  system  and  software  architecting,  designing,  coding  and  software  level  integration 
and  test.  The  System’s  SW  requirements,  design,  code  and  test  artifacts  are  developed 
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almost  entirely  by  Industry.  Government  insight  into  the  detailed  software  architecture  and 
design  is  primarily  via  the  utilization  of  milestone  reviews  (System  Requirement  Reviews 
(SRRs),  Preliminary  Design  Reviews  (PDRs),  etc.).  The  government  then  takes  the  lead  for 
System  Integration,  Testing  and  Certification.  And  as  described  in  the  next  section,  this 
acquisition  approach  fails  more  often  than  not  with  regards  to  cost,  schedule  and 
performance. 
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Figure  2.  Current  Acquisition  Approach 


Figure  3.  Current  Acquisition  Approach 


Current  State:  Results 

The  increase  in  DoD/Navy  SW  intensive  warfare  system  cost,  schedule,  and 
technical  performance  failures  over  the  past  20  years  are  well  documented  in  numerous 
reports  and  studies  from  organizations  such  as  the  Defense  Science  Board  (DSB),  the 
Government  Accountability  Office  (GAO),  Crosstalk,  and  Assistant  Secretary  of  the  Navy 
Research  Development  and  Acquisition  (ASN/RDA).  Figure  4  summarizes  some  of  the  key 
studies  and  their  cost,  schedule,  and  quality  metrics. 
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The  November  2002  Report  of  the  DSB  Task  Force  on  Defense  Software  reported: 

■  Only  16%  of  programs  are  completed  on  schedule  and  within  budget 

■  Up  to  31%  of  programs  are  cancelled  and  the  remaining  53%  have  cost  growth 
greater  than  89% 

■  The  average  final  product  includes  only  61  %  of  the  original  intended  features. 
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2007  ASN/RDA  Software  Process 
Improvement  Initiative  (SPII)  As  Is  Report  - 
For  SW  Acquisition  Management 

-  7  Key  problems  still  exist 

1.  Lack  of  effective  acquisition  management 

2.  Immature  acquirer  (program  offices) 

3.  Ineffective  requirements  management 

4.  High  personnel  turnover  in  the  acquiring  org. 

5.  Cost  and  schedule  estimation  accuracy 

6.  Ineffective  utilization  of  EVMS  for  SW  systems 
Failure  to  take  advantage  of  Lessons  Learned. 


(1 )  “Over  time,  in-house  offices  of  subject  matter  experts  were  drastically  reduced,  and  in  some  cases,  disestablished”;  (2)  “Finally,  there 
was  a  loss  of  a  large  number  of  the  most  experienced  management  and  technical  personnel  in  Government  and  industry  without  an 
3.  adequate  replacement  pipeline”;  (3)  “Many  IOT&E  failures  have  been  due  to  lack  of  operational  suitability.” 

(Report  of  the  Defense  Science  Board  [DSB]  Task  Force  on  Developmental  Test  and  Evaluation,  2008) 


Figure  4.  DoD  Software  System  Acquisition  Report  Findings 


In  2004,  the  GAO  reported  that  the  DoD  spent  40%  of  its  software  development 
budget  reworking  software  because  of  quality  related  issues  (GAO,  2004).  In  2008  the  DSB 
reported  that  the  majority  of  DoD  weapons  systems  are  failing  Initial  Operational  Testing.  In 
2008,  the  ASN/RDA  SPII  SAM  focus  team  published  a  report  that  documented  the  following 
critical  problems  that  apply  to  the  vast  majority  of  DoD/Navy  SW  program  acquisition  offices: 


Lack  of  effective  management. 

Immature  acquirer  (program  offices). 
Ineffective  requirements  management. 
High  personnel  turnover. 

Unrealistic  cost  and  schedule  estimates. 


Ineffective  utilization  of  Earned  Value  Management  Systems  (EVMS)  for  SW. 
Failure  to  utilize  of  lessons  learned. 
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In  2009,  Senator  Carl  Levin  reported  that  since  2006  nearly  half  of  the  DoD’s  largest 
acquisition  programs  have  exceeded  Nun-McCurdy,  and  that  95  major  defense  programs 
have  had  their  acquisition  costs  grow  by  an  average  of  26%  and  have  experienced  an 
average  schedule  delay  of  almost  2  years. 

The  DoD  has  lost  the  ability  and  expertise  required  to  consistently  successfully  team 
with  industry  to  acquire  SW  intensive  weapon  systems  on  time  and  within  budget. 


Current  State:  The  Devil  Is  in  the  Details 

Although  software  has  evolved  into  one  of  the  most  complex  and  critical  elements  of 
mission  critical  systems,  the  typical  DoD/Navy  acquisition  strategy  tends  to  treat  the 
software  components  as  black  boxes  with  the  internal  software  architecture  and  design 
development  (and  understanding)  left  almost  entirely  in  the  hands  of  private  industry 
software  engineers.  As  shown  in  Figure  5,  a  typical  SW  system  may  include: 

■  Hundreds  to  thousands  of  system  level  requirements, 

■  Thousands  to  tens-of  thousands  software  level  requirements, 

■  Tens  to  hundreds  of  external  system  interfaces, 

■  Hundreds  to  tens  of  thousands  computer  software  components  (CSCs), 

■  Thousands-to  tens  of  thousands  internal  software  interfaces  and  interactions, 

■  Millions  to  hundreds  of  millions  of  logic  threads, 

■  Millions  to  hundreds  of  millions  of  source  lines  of  code  (SLOC),  and 

■  Billions  of  software  characters. 


And  note  that  all  it  takes  is  for  single  erroneous  character  within  the  millions  of  lines 
of  SW  to  cause  a  total  system  failure. 
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Devil  is  in  the  Details 
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Figure  5.  System  and  Software  Complexity 
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One  of  the  most  significant  challenges  facing  the  DoD/Navy’s  complex  software 
intensive  system  acquisition  is  the  rapid  rate  of  change  associated  with  software 
technologies,  methodologies,  processes,  processors,  and  tools.  In  order  for  program  office 
leadership  to  successfully  maintain  existing  software  systems,  and  acquire  new  software 
systems,  it  is  imperative  that  they  have  access  to  in-house  technical  experts  that  have 
applied  expertise  with  both  the  older  software  environments  and  the  latest  cutting  edge 
software  technologies  and  environments. 

In  addition  to  having  experience  working  with  the  latest  software  technologies, 
Government  in-house  software  engineers  must  also  be  able  to  apply  these  technologies  to 
the  unique,  complex,  and  challenging  context  of  Navy  system  functional  requirements  (e.g., 
time  critical  processing,  real-time  processing,  numerous  external  and  internal  hardware  and 
software  interfaces,  complex  algorithms,  safety  critical,  and  nuclear  critical).  The  current 
typical  acquisition  approach  limits  the  government’s  technical  understanding  to  a  few  pages 
of  high  level  system  and  software  architecture  diagrams,  and  understanding  and 
“controlling”  the  interfaces  between  the  software  components  only  at  the  highest  level  of 
system  abstraction,  the  Government  is  not  able  to  maintain  corporate  technical  expertise 
required  to  successfully  acquire  software  intensive  systems. 

The  allocation  of  all  the  software  architecture,  design,  code,  and  test  responsibility  to 
private  industry  is  causing  the  government  to  lose  the  applied  SW  development  experience 
and  expertise  to  consistently  successfully  perform  all  of  the  following  critical  software  system 
intensive  acquisition  activities: 

■  Maintain  awareness  and  expertise  in  modern  SW  technologies  and 
methodologies  necessary  to  understand  when/if/how  these  new  technologies 
should  be  utilized; 

■  Assess  industry’s  technical  approaches,  and  also  provide  government  developed 
technical  approaches; 

■  Evaluate  industry’s  technical  cost  and  schedule  estimates; 

■  Ensure  Open  Architecture  (OA)  design  and  verify  that  the  OA  design  is  actually 
implemented  in  the  SW  code; 

■  Fully  understand  the  technical,  cost,  and  schedule  impacts  of  requirement 
changes 

■  Define  and  manage  SW  EVMS; 

■  Define  and  utilize  SW  metrics-based  control  processes;  and 

■  Identify  and  manage  software  risks. 

Architecting  and  designing  only  at  the  higher  levels  of  system  abstraction  (i.e., 
segment,  component,  and  functional  domain)  is  not  sufficient  for  the  government  to  maintain 
applied  SW  expertise.  The  amount  of  required  expertise,  experience,  and  effort  required  to 
successfully  architect  and  design  the  software  components  increases  at  each  lower  level  of 
system  decomposition.  An  applied  in-depth  understanding  of  software  technologies  and 
methodologies  is  necessary  to  architect,  design,  and  implement  the  software  components  at 
the  CSCI  level  and  below.  The  government  must  understand  the  sub-component  SW 
elements  to  successfully  address  the  following  technical  challenges: 

■  Asynchronous  real-time  event  processing, 

■  Time  Critical  (milli/micro/nano  second)  accuracy  and  timing, 
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■  Safety  Critical  requirements, 

■  Anti-Tampering  and  Information  Assurance  protection, 

■  Data  Security/Classification  protection  and  segregation, 

■  24/7  system  reliability  and  system  accessibility,  and 

■  Protection  against  Cyber-Attacks. 

The  typical  acquisition  approach  of  Milestone  reviews  provide  too  little  insight  and 
occur  too  late  in  the  acquisition  schedule  as  the  damage  has  already  been  done.  Many 
“design”  reviews  now  focus  more  on  compliance  to  SW  processes  versus  actually  providing 
an  in-depth  review  of  the  SW  architecture/design/code.  Even  if  private  industry  provides  a 
detailed  and  thorough  presentation  of  their  software  architecture  and  design  at  the  milestone 
reviews,  the  government  typically,  except  for  a  few  rare  cases,  lacks  the  applied  in-house 
software  experience  and  expertise  to  ensure  the  software  components  meet  all  OA 
objectives  including  modularity,  scalability,  reliability,  maintainability,  and  quality;  and  ensure 
the  implementation  artifacts  (code)  and  design  artifacts  remain  consistent  with  each  other.  If 
the  government  identifies  any  significant  technical  software  architecture  or  design  issues 
during  the  milestone  review,  the  contractor  typically  responds  with  such  severe  cost  and 
schedule  impacts  that  often  the  only  option  left  is  to  trade-off  planned  new  capabilities  for 
significant  architecture  and  design  corrections. 

Some  software  intensive  programs  utilize  government  in-house  software 
engineers  to  participate  with  industry  during  software  development.  This  participation  is 
typically  via  peer-review  during  design  and  code  activities.  This  approach  assumes  that 
Government  software  engineers  will  be  willing  to  review  other  engineer’s  work  rather  than 
being  responsible  for  designing  and  coding  software  components  themselves.  The 
government  cannot  attract  the  best  talent,  nor  sustain  highly  motivated  and  high  quality 
software  SMEs  by  limiting  their  tasking  to  looking-over-the-shoulders  of  industry  software 
engineers.  Government  SW  engineers  must  have  hands-on  development  responsibility  in 
order  to  maintain  expertise. 

Future  State:  SW  Acquisition  Goals 

The  primary  goal  is  to  improve  the  DoD/Navy’s  ability  to  consistently  deliver  high 
quality  SW  intensive  weapon  systems  that  fully  meet  the  warfighters’  needs,  while  also 
delivering  these  systems  in  both  a  timely  and  cost  effective  manner. 

A  second  major  goal,  as  shown  in  Figure  6,  is  to  achieve  truly  Open  Architected 
systems  and  move  from  stove-pipe,  proprietary,  redundant  and  non-common  systems 
towards  product  line  multi-platform  non-proprietary  common  reusable  systems  and  software 
components.  Achieving  truly  OA  systems  will  improve  system  quality,  promote  competition 
and  innovation,  and  reduce  cost  and  schedule. 
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Open  Architecture  and  Product 


Line  Initiatives 


Current  Platform  Based  Stove _ -Pipe  Systems  Future  OA  Based  Product _ -Line  Systems 

Common,  Reusable, 

Scalable,  Modular 


Support 

Domain 


Figure  6.  Open  Architecture  Goal 


Future  State:  Team-Based  SW  Acquisition  Approach 

In  order  to  achieve  these  major  goals,  the  DoD/Navy  must  reconstitute  and  maintain 
a  sufficient  level  of  SW  expertise  with  the  applied  experience  required  to  team  with  Industry 
and  address  the  numerous  SW  development  technical  challenges.  Figures  7  and  8 
comprise  a  high-level  model  of  an  alternative  SW  acquisition  approach  that  enables  the 
government  to  maintain  applied  SW  engineering  expertise. 
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Figure  7.  Alternative  SW  Acquisition  Approach 
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Open  Architecture  Initiative 
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Componentizes  Software  Applications 


Distribution  Statement  F:  Release  is  not  authorized;  Further  dis  semination  is  only  directed  by  NSWCDD  or  higher  authority. 


Figure  8.  Government  SW  Development 

The  key  differences  between  this  SW  acquisition  approach  and  the  typical  approach 
is  that  the  government  SW  engineers  are  responsible  for  developing  and  delivering  a  subset 
of  the  mission  critical  tactical  system  and  software  components.  Government  in-house  SW 
engineers  are  responsible  for  developing  and  delivering  the  associated  technical  artifacts  for 
their  SW  components,  including  requirements  specifications,  architecture  and  design 
documents,  code,  and  test  procedures.  Note  that  Industry  will  still  develop  the  vast  majority 
of  the  SW  components  and  artifacts. 

The  government  SW  engineers  are  also  responsible  for  providing  the  critical 
management  products  as  well  including  development  process  documents,  metrics, 
schedules,  cost/schedule  progress  (EVMS),  interdependencies,  and  risks.  This  is  required  to 
develop  and  maintain  in-house  SW  SMEs  with  the  applied  experience  required  to  be  able  to 
successfully  architect,  design,  and  manage  (accurately  estimate  and  track  cost,  schedule, 
and  risk)  the  software  development  effort  at  all  levels  of  software  intensive  system 
decomposition  (Functional  Domain,  Component,  Segment,  CSCI,  and  down  to  the  CSCI 
sub-component  Object  and  Class  level). 

The  government  SW  engineers  are  given  the  opportunity  to  provide  SW  prototypes 
and  advanced  technology  and  methodology  approaches  during  the  pre-milestone  A  and  B 
acquisition  phases. 
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The  SW  artifacts  (requirement  specs,  design  documents,  code,  etc.)  are  developed 
by  Integrated  Government  and  Industry  SW  development  teams  that  utilize  cross 
organizational  design/code  peer  reviews  to  ensure  high  quality  products  and  conformance  to 
best-practices. 


The  government  SW  Development  engineers  have  the  same  expectations  and 
requirements  relative  to  cost,  schedule  and  technical  performance  as  their  industry  peers. 
System  testing  is  performed  by  an  independent  government  team  with  a  separate 
management  chain  of  command  from  the  government  SW  team. 


By  assigning  actual  SW  development  responsibility  to  in-house  engineers,  the 
government  can  reconstitute  and  maintain  the  SW  expertise  pipe-line  as  shown  in  figure  9, 
and  thereby  develop  the  senior  level  SW  expertise  required  to  perform  as  peer  level  team¬ 
mates  with  Industry.  This  approach  will  provide  in-house  software  SMEs  that  maintain 
applied  experience  and  corporate  knowledge  (as  the  system  evolves  and  as  some  of  the 
component  development  is  conducted  by  different  industry  organizations  over  time)  with: 


Complex  system  and  software  functional  requirements  such  as:  Safety  critical, 
Mission  critical,  Complex  external  and  internal  interfaces,  Real-time  processing 
Security  sensitive  data  processing,  and  Complex  algorithms; 

Latest  software  technologies  and  methodologies;  and 

Applied  open  architecture  (modular,  scalable,  reusable,  maintainable,  and 
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house.  There  is  no  well  defined  criteria  or  process  for 
assigning  sw  development  to  in-house  engineers. 
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Figure  9.  SW  Expertise  Pipeline  Future  State:  Success  Examples 

The  alternative  government  and  industry  SW  development  team  acquisition 
approach  described  in  the  previous  section  has  been  successfully  utilized  for  over  50  years 
by  the  Naval  Surface  Warfare  Center  Dahlgren  Division  (NSWCDD)  for  various  strategic  and 
tactical  weapon  and  fire  control  missile  and  gun  systems.  For  example,  NSWCDD 
government  software  engineers  have  been,  and  still  are,  responsible  for  the  architecting, 
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designing,  coding  and  testing  of  many  of  the  most  critical  and  complex  (e.g.,  safety  critical, 
real-time,  highly  complex  algorithms,  external  and  internal  interface  functionality)  software 
components  for  programs  such  as  the  Tactical  Tomahawk  Weapon  Control  System 
(TTWCS). 

The  government  SW  engineers  have  successfully  worked  with  private  industry  SW 
engineers  as  an  integrated  SW  development  team.  The  cost,  schedule,  and  technical 
performance  of  these  SW  IPTs  have  been  consistently  exceptional  over  multiple  decades  as 
compared  to  the  vast  majority  of  complex  weapon  system  programs  that  have  relied 
primarily  on  industry  for  the  SW  development  and  have  failed  (per  the  references  and 
metrics  provided  previously).  The  TTWCS  SW  IPT  has  been  consistently  successful  in 
meeting  the  SW  technical  challenges  and  future  state  goals  as  previously  described  in  this 
paper.  Some  specific  examples  are  provided  in  the  following  paragraphs. 

Over  the  past  several  decades,  the  TTWCS  SW  IPT  has  consistently  successfully 
delivered  software  upgraded  to  incorporate  and  integrate  the  latest  SW  technologies; 
evolving  from  Mil-spec  processors  (ROLM  1666)  to  modern  processors  (HP744,  X86);  from 
mil-spec  operating  system  (RMX/RDOS)  to  open  system  OS  (LINUX);  from  first  generation 
programming  languages  (Assembly,  Fortran)  to  modern  languages  (Ada,  Java,  C,  C++). 

The  SW  IPT  has  successfully  incorporated  new  SW  development  methodologies; 
transitioning  from  functional  design  to  object-oriented  design,  from  waterfall  development  to 
spiral/increment  development;  from  human-only  generated  coding  to  graphic-user-interface 
and  auto-code  generation  tools;  from  point-to-point  interfaces  to  FDDI/ETHERNET  H/W  and 
SOA-based  SW  interfaces. 

The  TTWCS  IP  has  achieved  and  demonstrated  Open  Architecture  design  and 
implementation.  As  shown  in  Figure  10,  the  TTWCS  SW  engineers  utilized  object-oriented 
design  to  achieve  scalability  and  reusability  with  regards  to  the  goal  of  easily  interfacing  with 
multiple  platforms  and  their  unique  launching  systems.  The  TTWCS  System  has  been  easily 
upgraded  to  support  not  just  US  Surface  Ship  Vertical  Launching  Systems,  but  also  US 
Submarine  and  United  Kingdom  Royal  Navy  Submarine  platforms.  When  the  TTWC  system 
was  recently  upgraded  to  interface  with  the  SSGN  platform,  within  less  than  a  year  the 
government  SW  engineers  were  able  to  define  the  SW  req’s,  document  the  design 
modifications,  implement  and  test  the  associated  new  Launcher  Interface  code  changes.  In 
addition,  SW  Components  were  reused  from  the  TTWCS  SW  within  the  SSGN  Launching 
System  software  which  resulted  in  a  faster  than  usual  successful  integration  of  the  two 
systems. 

The  TTWCS  system  has  successfully  met  interdependency  deliveries  with  the 
Tomahawk  missile  segment  upgrades  and  passed  the  vast  majority  of  its  Initial  Operational 
Test  Events. 

The  resulting  quality  of  the  TTWCS  SW  has  been  consistently  high  with  the 
integrated  SW  meeting  all  KPPs  and  with  SW  quality  consistently  averaging  little  over  1 
Defect/KSLOC.  And  more  importantly,  the  TTWCS  software  developed  by  the  government 
and  industry  team  has  performed  exceptionally  well  in  tactical  operations. 


ACQUISITION  RESEARCH  PROGRAM 

GRADUATE  SCHOOL  OF  BUSINESS  &  PUBLIC  POLICY 

NAVAL  POSTGRADUATE  SCHOOL 


213 


Figure  10.  Open  Architecture  Design 

In  addition  to  working  for  the  large  (multi-million  source  lines  of  code),  multi-year 
TTWCS  development  effort;  the  industry  and  government  SW  team  approach  has  also  been 
demonstrated  to  also  work  well  for  rapid  development  efforts.  Government  engineers  have 
teamed  with  industry  to  utilize  agile  SW  development  methodology  to  successfully  deliver 
the  integrated  sensor  and  weapon  capabilities  for  marine/army  vehicles  such  as  Gunslinger, 
Full  Spectrum  Effects  Platform  (FSEP),  and  Wolfpack.  This  integrated  agile  development 
team  has  also  been  utilized  for  the  Naval  Expeditionary  Overwatch  (NEO)  Intelligence, 
Surveillance,  and  Reconnaissance  (ISR)  systems.  These  rapid  development  efforts  were 
lead  by  government  engineers  that  quickly  assessed  and  integrated  multi-vendor  hardware 
and  software  technologies  to  provide  the  deployed  warfighters  with  much  needed 
capabilities  that  met  emergent  mission  critical  needs. 

Future  State:  Team-Based  SW  Development  Benefits 

As  demonstrated  by  the  consistent  success  of  the  TTWCS,  SLBM,  and  Rapid 
Development  weapon  programs  highlighted  in  the  previous  section,  the  government  and 
industry  SW  development  team  model  is  not  just  a  theory.  There  are  many  benefits  to 
utilizing  this  SW  acquisition  approach.  The  senior  level  government  SW  engineers  are 
capable  of  working  with  industry  to  address  the  significant  SW  challenges  that  include: 

Designing  and  implementing  truly  Open  Architected  systems  that  fully  meet  the 
goals  of  standardized  interfaces,  scalability,  reliability,  portability,  modularity  and  reusability; 
and  thereby  lead  to  higher  system  quality  while  also  reducing  cost  and  schedule. 
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■  Successfully  assessing  and  rapidly  integrating  the  most  advanced  software 
technologies  and  methodologies  into  the  SW  development  processes, 
environments  and  systems. 

■  Successfully  integrating  the  complex  mix  of  legacy  SW  components,  new 
Commercial-Off-The-Shelf  (COTS)  SW  and  hardware  components  and 
DoD/Navy  developed  highly  specialized  SW  components  to  provide  integrated 
net-centric  systems  that  can  execute  as  systems-of-systems  and  fully  meet 
mission  level  objectives  and  KPPs. 

■  Delivering  systems  with  demonstrated  Information  Assurance  (IA)  and  protection 
against  SW-based  Cyber-Attacks,  while  maximizing  the  utilization  of  COTS  and 
Net-Centric  architectures. 

In  addition  to  addressing  the  technical  challenges  above,  the  reconstitution  of  in- 
house  SW  expertise  will  also  enable  mitigation  of  the  following  key  problems  identified  in  the 
ASN/RDA  SPII  SAM  AS-IS  and  TO-BE  State  Reports. 

■  The  Program  Offices  will  have  access  to  in-house  SW  experts  with  the  technical 
and  acquisition  process  experience  to  aid  the  program  offices  in  managing  the 
industry  development  teams. 

■  The  in-house  experts  will  have  the  applied  knowledge  to  assess  industry 
technical  approaches  and  also  their  SW  development  processes.  This  includes 
having  in-house  experience  and  metrics  from  SW  cost  and  schedule  estimates 
and  thereby  be  able  to  provide  support  for  independent  cost  and  schedule 
assessments. 

■  The  in-house  SW  experts  will  have  applied  experience  with  developing  and 
implementing  system  requirements  at  all  levels,  and  this  will  enable  them  to 
support  requirement  management  and  volatility  risk  reduction. 

■  The  government  SW  engineers  will  have  in-depth  knowledge  of  various  weapon 
system  architectures  and  maintain  the  corporate  knowledge  required  to  mitigate 
the  risk  of  program  office  leadership  and  personnel  turnover. 

■  The  in-house  SW  engineers  will  have  applied  experience  with  EVMS  and  can  aid 
the  program  offices  in  setting  up  realistic  and  meaningful  SW-based  EVMS 
processes  and  tools. 

■  By  maintaining  SW  engineers  with  applied  experience  in  both  previous  and 
current  complex  SW  development  efforts,  the  program  offices  will  have  a  source 
of  objective  lessons  learned  and  metrics  that  can  be  applied  to  future  SW 
development  process  improvement. 

Another  challenge  of  relying  on  private  industry  for  100%  of  the  software 
development  is  that  it  leaves  the  program  office  with  no  leverage  over  the  contractor;  and 
with  very  few  schedule,  cost  or  performance  risk  mitigation  strategies  when  the  private 
contractor  is  failing  to  meet  the  program  needs.  By  the  time  the  program  office  realizes  the 
contractor  has  significant  problems,  the  program  is  in  “too  deep”  with  that  company  to  have 
any  other  choice  than  to  continue  funding  the  poor  performing  contractor  and  hope  for  the 
best. 


Firing  the  contractor  and  transferring  the  work  to  another  private  industry  contractor 
is  rarely  a  viable  option.  The  impact  to  cost  and  schedule  is  such  that  the  only  risk  mitigation 
options  include: 
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■  Significantly  increasing  funding 

■  Significantly  delaying  the  schedule 

■  Significantly  reducing  or  eliminating  planned  capabilities 

■  Canceling  the  program 

By  establishing  and  maintaining  integrated  SW  development  teams,  the  program 
office  leadership  will  have  the  option  to  augment  the  contractor  SW  team  with  on-site 
government  SW  engineers,  or  transfer  the  responsibility  for  SW  component  development 
from  the  contractor  to  the  Government.  This  can  be  accomplished  easily  as  the  Government 
software  engineers  are  part  of  the  software  development  team  from  the  beginning.  There 
will  be  no  need  to  perform  a  costly  re-competition  to  assign  the  work  to  another  private 
industry  team  that  would  be  unfamiliar  with  the  program  requirements  and  plan.  Under  the 
proposed  new  software  acquisition  strategy,  the  Government  would  have  contracts  in  place 
that  specify  all  developed  system  artifacts  become  the  property  of  the  US  Government.  This 
mitigation  technique  only  accelerates  the  delivery.  There  is  of  course  still  some  added 
schedule  risk  as  the  in-house  team  must  work  with  the  contractor  to  transfer  all  necessary 
artifacts  to  assume  full  development  responsibility.  If  the  program  office  and  development 
items  established  an  Integrated  Development  Environment  (IDE)  however,  this  transfer  of 
artifact  responsibility  is  relatively  easy. 

Program  offices  will  also  have  the  option  of  directing  the  Government  in-house 
software  experts  to  provide  onsite  support  to  aid  the  contractor  in  recovering  schedule 
progress  or  resolving  technical  problems.  Given  the  DoD  approach  for  rotating  the  military 
leaders  to  gain  a  wide  range  of  experiences,  it  is  common  for  a  software  intensive  system  to 
have  acquisition  program  leadership  personnel  that  have  no  significant  training  or,  more 
importantly,  any  applied  experience  in  software  engineering.  A  closely  related  challenge  is 
that  acquisition  program  office  leadership  transition  may  occur  at  any  point  during  the 
system  development  effort. 

A  single  Program  manager  may  not  manage  the  system  acquisition  and 
development  program  from  the  beginning  (version  content  definition)  completely  through  to 
the  end  (through  IOC).  The  development  organizations  are  faced  with  the  challenge  of  still 
meeting  the  previously  defined  development  milestones  and  delivery  dates,  while 
simultaneously  changing  organizational  structures,  reporting  chain  of  commands,  tasking 
priority  changes,  funding  reallocation,  and  development  process  changes  directed  by  the 
new  leadership.  Maintaining  an  experienced  Government  SW  development  organization 
mitigates  the  impact  of  frequent  senior  leadership  changes.  The  experienced  SW 
development  team  can  provide  the  following  benefits  to  the  acquisition  office’s  new 
leadership: 

■  Maintain  critical  system  functional,  architectural,  and  design  corporate  knowledge 

■  Aid  the  new  leadership  in  quickly  coming  up  to  speed  on  the  history  of  the 
program,  the  system’s  architecture  and  functionality,  the  various  development 
organization’s  roles  and  responsibilities,  current  development  process,  and 
status  of  the  current  development  efforts  (schedule,  progress,  and  risk) 

■  Provide  impact  assessment  for  proposed  organizational  and/or  process  changes 

■  Perform  the  Technical  Authority  responsibilities  for  those  leaders  without 
extensive  training  or  applied  experience  in  software  intensive  systems 
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Future  State:  Establishing  the  Pipe-Line 

The  DoD/Navy  must  re-assume  leadership  of  software  architecture  and  design. 
Government  software  architecture  and  technical  authority  must  be  demonstrated  not  just  at 
the  highest  system  composition  level  (i.e.,  Objective  Architecture  Functional  Domain  level), 
but  must  extend  down  into  lower  critical  sub-component  levels  as  well  as  illustrated  in  Figure 
10.  In-house  software  SMEs  should  serve  as  the  software  technical  authority  and  the 
software  architects,  and  lead  critical  software  sub-element  development  IPTs. 

The  DoD/Navy  must  develop  and  document  a  software  acquisition  improvement 
vision  with  a  quantifiable  goal.  Critical  weapon  and  warfare  system  program  offices  should 
work  with  the  in-house  software  development  organizations  to  develop  transition  plans  to 
achieve  the  vision  goals.  This  software  expertise  pipeline  must  be  continually  fed  and 
maintained.  In  order  to  attract  and  keep  the  best  and  brightest  software  engineers,  the 
Government  must  offer: 

■  Challenging  software  development  and  leadership  responsibilities 

■  Opportunities  of  architecting,  designing  and  implementing  solutions  to  the  most 
complex  types  of  system  functional  capabilities  and  problems 

■  Opportunities  to  utilize  the  latest  software  technologies,  methodologies, 
processes,  tools 

Government  engineers  should  not  be  limited  to  developing  tactical  software  only 
(where  tactical  software  is  defined  as  software  utilized  with  delivered  warfighting  systems 
with  strategic  or  tactical  mission  critical  requirements).  They  must  stay  abreast  and  have 
applied  expertise  with  all  the  latest  software  technologies.  In  addition  to  performing  tactical 
SW  development,  another  way  to  achieve  this  goal  is  to  assign  non-tactical  (e.g.,  system  or 
architecture  modeling  software,  simulation  software,  testing  software,  media  generation 
software,  data  distribution  software)  to  in-house  engineers.  It  is  often  possible  to  use  the 
latest  software  development  technologies  and  methodologies  for  non-tactical  software  as 
the  acquisition  cycle  may  be  much  shorter  and  the  certification  process  less  stringent  than 
for  tactical  systems 

Development  of  non-tactical  and  non-critical  software  components  can  serve  as  a 
test  bed  and  as  a  cost,  schedule,  and  technical  performance  risk  mitigation  strategy  for 
determining  if  new  software  technology  is  of  sufficient  maturity  and  capability  to  be 
incorporated  into  the  current  or  next  version  of  critical  tactical  system(s).  The  two  key 
questions  that  must  be  addressed  when  determining  what  software  should  be  assigned  to  a 
Government  software  development  organization  are: 

1 .  Will  this  assignment  help  maintain  the  software  expertise  pipeline? 

1 .  Will  this  assignment  maintain  corporate  expertise  and  mitigate  the 
cost,  schedule,  and/or  technical  performance  risks  of  existing  or  future 
systems? 

As  directed  in  the  2008  Mr.  Donald  Winter  SECDEF  memo:  "This  combination  of 
personnel  reductions  and  reduced  RDT&E  has  seriously  eroded  the  Department's  domain 
knowledge  and  produced  an  over-reliance  on  contractors  to  perform  core  in-house  technical 
functions.  This  environment  has  lead  to  outsourcing  the  "hands-on"  work  that  is  needed  in- 
house,  to  acquire  the  Nations  best  science  and  engineering  talent  and  to  equip  them  to 
meet  the  challenges  of  the  future  Navy."  And  "In  order  to  acquire  DoN  platforms  and 
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weapons  systems  in  a  responsible  manner,  it  is  imperative  the  DoN  maintain  technical 
domain  expertise  at  all  levels  of  the  acquisition  infrastructure." 

The  current  undefined,  undocumented,  non-standardized,  and  non-disciplined  “ad 
hoc”  assignment  of  SW  development  to  in-house  SW  development  organizations  is 
insufficient  to  achieve  and  maintain  the  much  needed  SW  expertise  pipe-line.  The 
DoD/Navy  should  develop  a  well  defined  and  documented  software  development 
assessment  and  assignment  process  and  criteria.  This  process  and  criteria  will  be  utilized  by 
software  intensive  system  acquisition  program  offices  to  assign  software  development 
responsibility  to  integrated  government  and  software  development  teams. 
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Current  Future  Trend  Goals 

Trends 


*  Failures 

YR  2000:  84%  of  programs  are  late  and  over  budget,  and  deliveries  include  only  61%  of  planned  capabilities* 

YR  2004:  40%  ($8  Billion)  of  DoD  RDT&E  Budget  was  spent  on  reworking  software  due  to  quality  issues** 

YR  2009:  DOD’s  95  major  defense  acquisition  programs  have  an  average  cost  growth  of  26%  and  an  average  schedule  delay  of  almost  2  years*** 


Improvement  Recorrrnendations 

1.  Reconstitute  the  Navy’s  in-house  applied  sw  development  expertise  and  Leadership 

2.  Utilize  government  and  industry  software  development  Integrated  Product  Teams 
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♦  Designing  and  implementing  truly  Open  Architected  systems 

-  standardized  interfaces,  scalable,  reliable,  portable,  modular 

♦  Assessing,  successfully  utilizing,  and  rapidly  integrating  the  most  advanced  software 
technologies  and  methodologies: 

-  Model  Driven  Architectures,  Service  Oriented  Architectures  (SOA),  multi-core  parallel 
processing,  automated  code  generation,  cloud  computing,  next  generation  programming 
languages,  and  agile  development  processes. 

♦  Integrating  the  mix  of  legacy  and  modern  SWand  HW components 

-  new  ODriTTTerdal -Off-The-Shelf  (COTS)  SW  &  HW  components  and  DoD/Navy  developed  highly 
spedalized  and  unique  components 

-  Achieving  integrated  net-centric  systems  composed  of  hundreds-of-mi  1 1  ions  (possibly  billions)  of 
lines  of  code  that  can  execute  as  systems-of-systems  and  fully  meet  mission  level  objectives  and 
Key  Performance  Parameters  (KPPS). 


♦  Achieving  Information  Assurance  (IA)  and  protection  against  SW  based  Cyber-Attacks 
while  maximizing  COTS  utilization  and  Net-Centric  communications. 


♦  Maintaining  government  corporate  knowledge  of  the  system  architecture,  design  and 
technology  utilization  as  the  responsibility  for  system  and  software  development 
transitions  among  different  private  industry  organizations  during  the  program  life- 
cycle. 
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^^Acquisition  Approach 


♦  Software  size,  complexity,  and  reliance  is  continuing  to  grow  within  DoD/Navy  critical  systems 


♦  DoD/Navy  is  failing  to  consistently  successfully  acquire  software  intensive  systems 

-  YR  2000:  84%  of  programs  are  late  and  over  budget,  and  deliveries  include  only  61%  of  planned  capabilities* 

-  YR  2004:  40%  ($8  Billion)  of  DoD  RDT&E  Budget  was  spent  on  reworking  software  due  to  quality  issues** 

-  YR  2009:  DOD’s  95  major  defense  acquisition  programs  have  seen  their  costs  grow  by  an  average  of  26%  and 
experienced  an  average  schedule  delay  of  almost  2  years*** 

♦  DOD/Navy  is  losing  its  in-house  applied  software  engineering  and  development  expertise 


*  2000  Defense  Science  Board  (DSB)  Task  Force  on  Defense  Software  Report 
**  2004  General  Accountability  Office  Report 

***  2009  Opening  Statement  of  Senator  Carl  Levin  at  Senate  Armed  Services  Committee  Hearing,  March  3,  2009 
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Work  Share  Percentage 


Current  System  Acquisition  Strategy 
Ro/es  and  Responsibilities 


Concept  of  Operations 
System  Requirements 
System  Architecture 
System  Interfaces 


Government 


Requirements  development 


Software  Requirements 
Software  Architecture  and  Design 
Software  Interfaces 


Industry 


System  Design  and  Development 
Milestone  Reviews 


System  Integration 
System  Testing  /  Certification 
Operational  Support 

NON-Reusable 


System  Integration  and  Test/ 
Operations  and  Support 


CURRENT  STATE  CHARACTERISTICS: 

•Government  relies  primarily  on  Industry  for:  System  Requirements  Definition, 
System  and  Software  Architecture,  System  and  Software  Design  and  Development. 

•Non-open  systems. 

•Proprietary  system  artifacts. 
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Current  State 


^  ^  ^  IOC  FOC 

Materiel  \ 
Solutions 

l  ^  B  Engineering  and  Manufacturing  Dev  C 

^  Production  and 
Deployment 

Operations  and 
Support 

ITR 
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DoD/ASN/RDA  Policies  Call  for  Gov’t  SMEs  to  Define  System  Req’s,  Support  Milestone  Reviews,  and  Validate  the  SW  Artifacts  Developed  by  Industry 


Software  Development  Activities  Conducted  Primarily 
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In-House  Software  Expertise  Pipeline 


“In  order  to  acquire  the  DON  platforms  and  weapons  systems  in  a  responsible  manner,  it  is  imperative  the  DoN  maintain  technical  domain  expertise  at  all  levels  of  the 
acquisition  infrastructure 

-Department  of  the  Navy  Acquisition,  D.  Writer:  SECNAV  Memo  Dated  10  Oct  08 
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Future  State  Goal 

Open  Architecture  based  Product-Line  Initiative 


Current  Platform  Based  Stove-Pipe  Systems 


Future  Product-Line  Systems 


Platform  X 


Gov’t  owns  the  Syst 

artifacts 

(Specs,  Code, ..) 


Common,  Reusable, 
Scalable,  Modular 


External 

Comms 

Domain 

Disf 

Don 

)lay 

lain 

Vehicle 

Control 

Domain 

Weapon 

Sensor 

Mgmt 

Domain 

Track 

Mgmt 

Domai 

Comm 

Mgmt 

Domain 

Contro 

Domai 

Support 

Domain 

Ship 

Control 

Domain 

Infrastructure 

Domain 

Gov’t  owns 
the  System  Arch, 

Software  Arch,  and 
Interfaces 
*  Promotes  Cost 
Avoidance  and  Innovation 


Objectives 

-  Transition  from  Stove-Pipes  to  Product  Lines 

-  Reduce  Cost 

-  Promote  Competition  &  Innovation 

-  Deliver  High  Quality  Reliable  Systems 


Architecture  Characteristics : 

Decouples  Hardware  from  Software 
Utilizes  Standards-based  Interfaces  to  Network 
^Componentizes  Software  Applications 
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Future  State  Challenge: 

Maintaining  Corporate  Knowledge  of  Objective  Architecture 


♦  How  does  the  Navy  maintain  corporate  knowledge  and  ownership  of 
the  Objective  Architecture  as  the  system  evolves  over  time  and  is 
required  to  support  numerous  different  platforms? 
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Future  State  Challenge: 
Open  Architecture  Software 


'  Reference:  QA  Architectural  Principles  and  Guidelines  v  1.5.6,  2008,  IBM,  Eric  M  Nelson,  Acquisition  Community  VNfehsite  (ACC)  DAU  Navy  GA  Website 
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Future  State  Challenge:  Components  Size  and  Complexity 
Devi!  is  in  the  Details 


System  Component  Relative  Sizes 


Tens 

Hundreds 

FD  Req’s  and  l/Fs 

— 

Comp/Seg  Req’s  and  l/Fs 

swcsa 

swcsa 

2 

#,mm 

Software 

Components 


-  Maintainability 

-  Interoperability 

-  Connposability 


SLC 
SLOC2 

SLOCXXX,XXX 


Gov’t  SWSIVEs  must  ensure  OA  req’s  are  met  at  the 
most  detailed  levels  of  SW design  for: 

-  Open  Standards 

-  Reuse 

-  Modularity 

-  Extensibility 
Gov’t  SWSIVEs  must  understand  the  technical  design 
and  details  for  complex: 

-  Data  &  File  Management 

-  Threading  &Tasking  Hierarchy 

-  I  nitial  ization  /&Terrri  nation 

-  Time  Critical  &  Deterministic  Processing 

-  Intra  &  Inter  Process  Communications 

-  Fault  Processing 

-  Process  Prioritization 


CD 

< 

CD 


o 

o 

3 

■o_ 

<0 

X 


Thousands 


SWCSQ  Level  Req’s  and  l/Fs 


3: 

cq‘ 

3- 


csas 

CSCs 

Objects 

1  1 

Rles 

Millions 


Common  Hardware  and  Operating  Systems 


SLOCs 

A  single  erroneous  SLOC/Character  can  crash  the  entire  system 
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04  Success  Example 

Open  Architecture  Achieved  at  the  CSC/  and  Class  Leve/ 
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Work  Share  Percentage 


Alternative  System  Acquisition:  Integrated  Team 
Roles  and  Responsibilities 


Concept  of  Operations 
System  Requirements 

System  Architecture 

Software  Requirements 

Software  Architecture  and  Design 
Software  Interfaces 

System  Interfaces 

f  Reusable 

Components 

^Repository/  / 

Industry 

Government 

System  Integration 
System  Testing  /  Certification 
Operational  Support 


Reusable 

Components 


Requirements  development 


System  Design  and  Development 
Milestone  Reviews 


System  Integration  and  Test/ 
Operations  and  Support 


REQUIREMENTS 

Majority  of  Tech  Work  done  by  the  Gov’t 

Gov’t  Leads  AO  As  /  Industry  may  support. 
Gov’t  Leads  Prototyping  /  Industry  may  support. 
Gov’t  Defines  System  Requirements 
Gov’t  Defines  System/SW  Architectures. 

Gov’t  Defines  Interfaces  (I/F). 

Gov’t  Determines  what  system  components  will 
be  developed  by  Industry  and  In-house  SMEs. 


SYSTEM  DEVELOPMENT 

Majority  of  Technical  work  done  by  Industry 

Gov’t  controls  and  manages  Architectures  and  I/Fs 
Gov’t  leads  sw  design  and  development. 

Industry  develops  a  majority  of  the  sw  components. 
Gov’t  develops  a  small  subset  of  the  critical  sw. 


INTEGRATION  /  TEST 
Majority  of  Tech  work  by  Gov’t 

•  Gov’t  leads  System  Integration 

•  Gov’t  leads  System  Test  and  cert 

•  Gov’t  and  Industry  fix  SW  Defects 

•  Gov’t  controls  the  Common 
Asset  Library  where  final 
System  Products  are  stored 

•  Gov’t  maintains  the  SW 
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Integrated  Gov’t  and  Industry  Development  Teams 
Accountability 


♦  V\fell  defined  and  documented  roles  and  responsibilities 

♦  Common  set  of  well  documented  cost,  schedule,  and  performance  expectations 

-  Cost  and  schedule  Variance  (CPI/SPI)  Thresholds  and  Goals 

-  Quantified  Key  Performance  Parameters  and  Software  Quality  goals 

♦  Common  set  of  well  documented  system  development  processes  and  metrics 

-  Business  Processes  and  Technical  Processes 

♦  Integrated  Master  Schedule  (IMS)  with  well  defined  and  agreed  to  interdependency  products 
and  associated  delivery  dates 

♦  Proactive  and  attentive  integrated  team  management  of  cost,  schedule  and  technical 
performance 

-  Frequent  regular  periodic  team  communication  and  risk  assessment  /  management 

♦  Gov’t  test  team  is  independent  from  government  sw  development  team 

-  Separate  management  chains 

-  Test  team  has  direct  line  of  reporting  to  the  Program  Office 

♦  Utilization  of  IVSIestone  Reviews  with  Independent  Competency  Experts 
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Recorrrriendations 


♦♦♦  Reconstitute  the  government  in-house  Software  Expertise  Pipe-line 


♦♦♦  Work  with  Navy  senior  leaders  to  define  the  vision,  roles  and 
responsibilities  of  in-house  software  development  organizations 


♦♦♦  Develop  and  execute  the  transition  plan(s)  to  accomplish  the  vision 


Develop  and  maintain  in-house  technical  experts  who  can  lead  and 
participate  within  integrated  government  and  industry  software 
development  teams  that  utilize  best-practice  based  technical  and 
business  processes  to  provide  high  quality  and  reliable  War-fighter 
systems  that  fully  meet  cost,  schedule,  and  technical  performance 


Back-Up 


♦  Open  Architecture  Characteristics 

♦  Current  Typical  SW  Acquisition  Strategy 

♦  Devil  is  in  the  Details  (System  Decomposition) 
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System  Acquisition  /  Development 
Key  Elements  for  Success 


3  Key  Execution  Elements 


Business 
Processes 

Metrics 
based 
processes 


World  Class 
Products 


Technical 
Experts 

In-house 
Hands-on 
Subject  Matter 
Experts  (SMEs) 


Technical 

Processes, 


Government  In-House  Expertise  Pipeline 


Lira  amt  Program  Manage  in  tnt  P 


Technical  Pitt 


C  hill  I  trig  e  2 

Maintaining  Navy  mi- li  a  us  a  SW  irpaitita  i£H|uiiui  ihal 
an  a  p  (i  r  p  rlatc  iu  b  tti  if  c  til  ic  1 1  )  be  df  ve  lip  ed  I  it- 

house  Tlic rc  i t  no  define d  crttcria  or  process  lor 
assigning  cw  develop  in  till  1o  io-h  oris  a  (nigifiBars. 


Challenge  1 
Hon  SW  0  srfcg  roun  d 


flan*  gem  tut;  SycKmcej  Level 
Division  (IDO  to  Zfi If)  H emf 
Wariara  Cenlei  Pjegiam  .Manage; 


Ccmaln  and  System  Level  Leadership 

Ptignm  &  Line  Miitigeineirt: 

D  epa  i  fine  nt  He  ad  (BOO  +) 

Program  Manage  is  far  PEQi 


ria  nag  Bniaot:  Component  Level 
Branch  iff  to  4D)  Heart 


1  to  2  years 


Management  CSCIlej  Level 
SW  G  roup  <4  to  1 0)  Lei  d  erihlp 


Computer  SVf  Cenfigu ratlin  item  tCSCI) 
Lend  C3CI  Architecture  Design  and  Code 

-  Cresi  Discipline  IPT  participation 

-  CompErx  Tech  Problem  Resolution 


2  to  8  years 


Teehrlial  Leadership  an tfOverslg fit  | 
System  a  end  Domain  Level 
-  AiA  Leade  r  ship  an  it  Ex  ecutln  n 
-Cost  and  Schedule  Assessment 
-Teen  Approach  Leadership  £  Approval  | 

"TECHNICAL  ASSIGNMENT  LOOP-BACK" 

Seqmtnt  and  Companenl  LbvbI  Devi  I  a  pm  anl 
•  Lead  Arehtteclure  Design  and  Implementation 
-  Cross  CrgoniietionfFtmclion  1FT  Leadership  and  Participation 
Lead  Technology  insertion 


Senior  Level  sw  Experts 


3  years  + 


Time 


‘in  order  to  acquire  DON  platforms  and  mapens  systems  in  a  responsible  manner,  it  is  imperative  the  DoN 

maintain  technical  domain  expertise  at  aft  levels  of  the  acquisition  infrastructure'. 

-Department  of  FAe  Navy  Acquisition,  D.  Winter:  SECrtdVJtfemo  Dated  10  Oct  OB 


Metrics  Based  Business  Processes 

Program  Execution 


Integrated  Gov’t  and  Industry  Development  Team 


Analysis  and  Modeling 


Workforce 


Concept  Development  j| 


Alignment 


System  Req’s  and  l/Fs 


CMMI  Based 
Development  Processes 


SW  Arch,  Design,  Code, 
SW  integration  and  Test 


Financial  Execution 


System  Int  &  Test 
Operational  Support 


Cost,  Schedule,  Tech  Performance,  Risk  Management 
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Future  State 

Gov’t  and  Industry  SW Development 


Gov’t  develops  a  small  subset  of  the  sw  components  to  invest  in  the 
gov’t  acquisition  workforce  at  no  additional  cost  to  the  programs 

Gov’t  contracts  out  modular  components  to  promote  competition 
between  large  and  small  industry  partners 


Gov’t  owns  the 
System  artifacts 


Critical  Functional  Domain  Component 

Software  Architecture,  Interfaces  &  Elements 

G 

G 

G 

G 

G 

G 

G 

G 

G 

G 

(External 

Display 
_  Domain 

Vehicle 

Control 

Domain 

Weapon 
— Bfl^mt 

^«*rrfro 

r^jiTTail 

Domai 

l^Ship 

Support 

Domain 

Control 

Domain 

Infrastructure 

Domain 

lomm 

Control 

lomain 

Gov’t  owns 
the  System  Arch, 
Software  Arch,  and 
Interfaces 
*  Promotes  Cost 
Avoidance  and 
Innovation 


Common,  Reusable,  Scalable,  Modular 


Government  in-house  engineers  will  develop  (architect,  design,  code,  test)  a  subset  of  the  software 
Industry  software  engineers  will  still  develop  a  majority  of  the  software  components 
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REFRENCES  FOR  SOFTWAR  ACQUISITION  IMPROVEMENT 

DATE 

REPORT  /  STUDY  /  MEMORANDUM  /  POLICY 

AUTHOR /SPONSOR 

KEY  QUOTES  /  POINTS  /  METRICS 

OCT  10 
2008 

SECDEF  MEMO: 

Department  of  the  Navy  Acquisition 

SECDEF 

Donald.  C.  Winter 

"In  order  to  acquire  DON  platforms  and  weapons  systems  in  a 
responsible  manner,  it  is  imperative  the  DON  maintain  technical  domain 
expertise  at  all  levels  of  the  acquisition  infrastructure." 

"This  combination  of  personnel  reductions  and  reduced  RDT&E  has 
seriously  eroded  the  Department's  domain  knowledge  and  produced  an 
over-reliance  on  contractors  to  perform  core  in-house  technical  functions. 
This  environment  has  lead  to  outsourcing  the  "hands-on"  work  that  is 
needed  in-house,  to  acquire  the  Nations  best  science  and  engineering 
talent  and  to  equip  them  to  meet  the  challenges  of  the  future  Navy." 

"The  fraction  of  RDT&E  funding  at  each  warfare  Center  and  Laboratory 
should  be  maintained  at  a  level  sufficient  to  develop  and  sustain  the 
needed  technical  capabilities  of  the  DON". 

NOV  07 
2008 

Senators  Levin  and  McCain  letter  to  SECDEF 

Senator 

John  McCain 

Highlights  the  need  for  government  in-house  technical  expertise  in  the 
acquisition  workforce,  especially  in  the  technical  and  business  domain 

NOV  04 
2008 

ASN/RDA  MEMO:  Meeting  of  the  Navy 
Laboratory/Center  Competency  Group 

ASN/RDA  PCD 

James  E.  Thomsen 

"...strategic  imperatives  that  1  have  received  from  the  ASN(RDA&A)  and 
SECNAV..." 

STRATEGIC  OBJECTIVE  1:  Reverse  the  over-reliance  on  contractors 
performing  core  Navy  acquisition  functions. 

STRATEGIC  OBJECTIVE  2:  Stewardship  of  the  Navy's  Laboraties  and 
Warfare  Centers  to  ensure  long  term  health  and  effectiveness. 

STRATEGIC  OBJECTIVE  4:  Identify  and  develop  skilled  Program 
Managers  and  their  successors 

DEC  05 
2008 

ASN/RDA  MEMO: 

Strategy  to  Balance  Acquisition  In-house  and 
Contractor  Support  Capabilities 

ASN/RDA  PCD 

James  E.  Thomsen 

"1  expect  growth  in  the  organic  acquisition  workforce,  largely  offset  by  a 
corresponding  decrease  in  outsourced  core  acquisition  (technical  and 
business)  functions.  1  request  that  each  PEO/SYSCOM  team  submit  a 
time-phased  strategy  to  increase  acquisition  organic  capabilities  by 
reducing  dependence  on  outsourced  core  acquisition  functions." 
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JUL22 

2009 

ASN/RDA  MEMO: 

DON  Software  Measurement  Policy  for  Software 
Intensive  Systems 

ASN/RDA 

John  S.  Thrackrah 

Directs  all  programs  to  implement  the  following  core  set  of  metrics: 

•  Software  Size 

•  Cost/Schedule  (WBS  Focus  on  Software) 

•  Software  quality 

•  Software  Organization 

MAY 

2008 

Report  of  the  Defense  Science  Board  (DSB)  Task 
Force  on  Developmental  Test  and  Evaluation 

Office  of  the  Under 
Secretary  of  Defense  for 
Acquisition,  Technology 
and  Logistics 

"  In  recent  years,  there  has  been  a  dramatic  increase  in  the  numbers  of 
systems  not  meeting  suitability  requirements  during  IOT&E"." 

"there  was  a  loss  of  a  large  number  of  the  most  experienced 
management  and  technical  personnel  ...without  an  adequate  replacement 
pipeline" 

"changes  in  developmental  test  and  evaluation  alone  could  not  remedy 
poor  program  formulation". 

"sequential  workforce  cuts  in  the  last  ten  years  had  a  significant  adverse 
impact  on  the  DOD  acquisition  capability".  "A  significant  amount  of 
developmental  testing  is  currently  performed  without  needed  degree  of 
government  involvement  or  oversight" 

NOV 

2000 

Report  of  the  Defense  Science  Board  (DSB)  Task 
Force  on  Defense  Software 

Office  of  the  Under 
Secretary  of  Defense  for 
Acquisition  and 
Technology 

KEY  FINDINGS/METRICS 

(from  review  of  6  major  previous  DOD-wide  studies) 

•  only  16%  of  programs  complete  on  schedule  and  within  budget 

•  31%  of  programs  are  canceled  and  the  remaining  53%  have  cost  growth 
greater  than  89% 

•  the  average  final  product  includes  only  61%  of  original  intended  features. 

“..from  an  analysis  of  17  major  software  intensive  systems  that  the  level  of 
team  experience  with  requirements,  architecture,  and  technology,  and 
team  processes  and  communications  patterns  on  similar  systems  was  the 
dominant  reason  for  a  projects  success  or  failure..” 

"Software  is  rapidly  becoming  a  significant,  if  not  the  most  significant, 
portion  of  DOD  acquisitions." 

"Technology  is  changing  more  rapidly  than  ever  before. ..the  changes 
make  it  necessary  to  stay  abreast  of  the  technology,  how  to  apply  it,  how 
to  develop,  field  and  operate  the  systems  that  use  it". 

Recommendations. 

Improve  software  skills  of  acquisition  and  program  management. 
Strengthen  and  stabalize  the  technology  base. 
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FEB 

2008 

Report  to  Congressional  Committees  Best  Practices: 
Increased  focus  on  requirements  and  oversight 
needed  to  improve  DODs  Acquisition  Environment 
and  weapon  System  Quality  (GAO-08294) 

Government  Accounting 
Office  (GAO) 

Analyzed  1 1  major  DOD  weapon  Systems. 

"defense  contractors  poor  practices  for  system  engineering  activities  as 
well  as  manufacturing  and  supplier  quality  problems"  contributed  to 
significant  failures  wit  regards  to  cost,  schedule  and  technical 
performance. 

DOD  needs  to  adopt  a  knowledge  based  acquisition  approach. ..high 
levels  of  knowledge  must  be  demonstrated  at  critical  decision  points  in  the 
product  development  process 

2007 

2008 

ASN/RDA  Software  Process  Improvement  Initiative 
(SPII)  Software  Acquisition  Management  (SAM) 

Focus  Team  "As-ls"  and  'To-Be1'  State  Reports. 

ASN/RDA 

Chief  Engineer 

Assessed  numerous  previously  existing  DOD/Navy  studies  and  reports; 
and  found  the  following  7  common  SW  Intensive  System  Acquisition 
management  problems: 

Lack  of  effective  acquisition  management 

Immature  acquirer  (program  offices) 

Ineffective  requirements  management 

High  personnel  turnover  in  the  acquiring  organizations 

Unrealistic  Cost  and  Schedule  Estimates 

Ineffective  utilization  of  EVMS  for  SW 

Failure  to  take  advantage  of  lessons  learned 

'To-Be1'  report  recommendations  for  each  of  the  7  critical  problems  ALL 
include  requiring  the  government  to  train  and  better  utilize  Subject  Matter 
Experts  (SMEs). 
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